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COMMtJNICATION METHODS AND APPARATUS 



Tbe present invention rdates to methods and apparatus for communication between a user 
umt, sudi as a receiver/decoder^ and aremote unit« whidi may be, for example, an internet 
5 account management system or an internet s^ce provider. 

Recdver/deooders are used for receiving and/or decoding signals, such as television 
signals, which may be transmitted in analogue or digitd form. In the case of digital 
transmission* digital channels are CTcoded into a digital data stream at the transnntter end, 
10 and are decoded at the recover end using a receiver/decoder, which may be dther in a 
distal set-top box (DSTB) or in an integrated digital television, lb the case of analogue 
transmission, a receiver/decoder may be provided at«the subscriber to convert the 
transmitted signals into a format that may be displayed on a tdevision screen. 

IS Receiver/decoders typi(^y Contain a processor on which programs known as applications 
may be nan. An example of an application which may be run on a recdver/decoder is an 
internet access application^ whidi can allow a subscriber to access tfie internet by means 
of the receiver/decoder. 

20 Receiver/decoders tend to be of.relatively simple construction in order to ensure a low 
unitcost. Thiscanmakettdifficuhtosetuparecdver/decodo-tocomnuinicatewitha 
remote netwoilc, such as the internet In pardcular, communication with the internet 
requires the use of internet protocols and authentication which may be difBcult to 
implement on a recdver/decoder. For example, certain receiver/decoders may be able to 

23 output data in a format suitable for direct connection to Ae internet Such 
recdver/decoders are referred to^as^'non-IP envied*'. ^ 

Accor&ig to a first aspect, of the present invention there is provided a method of 
authenticating between a receiver/decod»' and a remote server, 

30 compri^ng uang an identifier of the receiver/decoder to authenticate the communication. 



By use of the invration. authentication of the communication between the 
receiver/decoder and the remote server can be based on a unique identifier of the 
receiver/decoder to which the receiver/decoder has ready access^ which can reduce the 
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requirements made of the reedver/decoder. 

Receiver/decodeis are often provided with a unique idpitifier for acxess to broadcast 
services^ which identifier may provide a conveoient means of identiQriiig the 
3 receiv^decodo^y and thus the identifier may be based on^an identifier for accw to 
broadcast services. Altfirnativdy; the identifier may be stored together with an Identifier 
for access to broadcast services. Preferably the identifier is stored on a removable 
component, such as a smartcard. 

10 Preferably the idtttifier is independent ofa network login identifier. This can reduce the 
complexity of the receive/decoder, since the identifier may be siflq)ler than a network 
login identifier, which tend to be complex muhicharscter identifiers to &cilitate 
memorising by a user. Another drawback with login identifiers is that they may change 
from time to time, or more than one may be required for access to different services; the 

15 invention may allow a single identifier supplied by a receiver/decoder to be associated (in 
a remote server) with a changeable network identifier or with a plurality of network 
identifiers. This feature may be provided independently. 

Prefer^ytheidoitifierisbasedonanuinberuiiiquetoasmfilrtcard. As used her^ the 
20 term "smartcard" inchiHes^ but not exclusively so, any chip-based card device, or object 
of similar fimction and poibrmance. possesffl^ for exan^le, microprocessor and/or 
memory storage. Included in tins term are devices haviiigahernativepfa^calfoniis to 
a card, for exanq)le key-shaped devices such as are often used in TV decoder syst^ns. 

25 The remote serv^ may be for accessing the internet, or it may be an internet account 
management system, or any other form of server, for example, for accessing a remote 
network of any form. 

The remote server may be for accesmig a network having network protocols, and data 
30 fit>m the receiver/decoder may be converted into data having the network protocols at a 
remote location from the receiver/decoder. In this way.«a receiver/decoder v^ch is not 
equipped with the network protocols may still communicate with the network. The 
netwoi^may be» for exanq}le, the internet, and the network pr6tocol may be, for example, 
transport control protocol / intend protocol (TCP/IP). The remote location may be. for 



example, at an operator, which may comprise an intern^ account management system. 

The above feature may also be provided independently, and tlms there may be provided 
a method of oommunicating betwe» a receiver/decoder and a remote netwoik wfaerdn 
5 the protocols necessary for communicatii^ witfi the ranote netwoik are inqilemented at 
a remote location from the receiver/decoder. 

The remote server may include an idratification database and the identifier of the 
receiver/decoder may be used for the retrieval of account details from said database. 

10 

The remote server majf Gooq>tise a data path to an internet service provider and the 
method may ftirther conq)rise die steps of providing retrieved account details to die 
internet service provide and establishing a bi-directional data pathway betwea the 
recelver/decodw and the internet secyice provider. 

15 

The idendfier may be accompanied by data indicating the data padiway to be used for 
communication between the user terminal and the remote device. In this way the 
receiver/decoder can spetify the pathway to be used fDr comnmnication; for exanqile 
a satellite link may be used for the remm channel. 

20 

In a preferred embodim^, die login details are in the form: 

login — {smartcard number) {type^if services} 
where the type of services (TOS) may specify the channels over which data 
commtfgiicarion is to occur, for exan^Ie, the case where a category of requmses are to 
2S be sent to die temiinalSy Satellite. 

The invMtion also provides a method of commnnicaring data from a non-internet 
protocol enabled user temiinal to one of plural internet protocol emdsled remote 
devices, die method comprising die steps of establishing a communications protocol 
30 between die user terminal and a multiplex unit* said protocol being arranged such that 
messages sent therein may include data to be communicated and may speciiy a 
destination from amoqgst the plural remote devices and wherdn said multiplex passes 
the data to the specified destination remote device. 
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The inyehtion ako provides a recaver/decoder far receivix^ t)roadca5t signals^ io which 
the receiver/decoder is ^d^^ to communicate with a remote server using an identifier 
of the receiver/decoder to authenticate the communicatioa The identifi^ may be based 
on an identifier for access to broadcast services. 



The invention also provides a gateway which is adapted to recdve data from a 
rec6iver/deGoder» ^di data are not m imemet protocol (such as TCP/IPX and to convett 
sud data into internet protocol for transmission to an internet service provider. 

10 Hie invention also provide a gateway for use in a data communications system of the 
type which includes a user unit and plural remote devices die gateway unit comprising: 
means for sending and receiving messages to and from the user unit; 
plural input / ouqntt ports each suitable for connection to aa individual one of 
said plural remote devices; 
IS ^eans for processing a received message so as t^ identify the remote device 

with the user unit wisl^ to establish a commimicarions channel; 

means for passing data forming part of received message and subsequently 
received messs^es to the identified remote device via die s^ropriate input / output port 
and for converting data subsequently received from the remote device via the 
20 appropriate input / output port into messages for communication to the user unit 
thereby establishing a communications channel between the user unit and the remote 
device. 

The gatewsQT may fiirtber comprise means for identifying a message from the user unit 
25 commandiiig termination of the cotnmunications channel^ and means for passing a 
termination command to the previously identified remote device. 

The gateway may fiirthor coinprise means for determining whether authentication of 
tile us^unit is required before the communications channel is established, means for 
30 sending a message to me uker unit requiring authentication in such a case» and means 
for analysbg a returned authentication message including authentication data received 
from the user unit and estaUishing said communications chamiel ^en said 
authentication data is deemed valid. 
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The gateway may be adapted such that commiinicatioiis between the gateway and the 
unit take place in a first fonnat and communicattans between the gateway and the 
remote device take place^in a second fonnat. 

5 In another aspect of ttic present invention there is provided a method of providing data 
identi^^ a user terminal bam said user terminal to a redtote device diaract^ed by 
the step of outputting^cnn said user terminal, identification data representative of a 
component of said user terminal. 



10 



30 



In a preferred embodiment the identification data includes data permitting the us^ 
terminal to log in to said remote device. 



The invention also provides a method of communicating data from a non^hitemec 
protocol enabled user terminal to one of plural internet protocol enabled remote 

15 devices, the method comprising the steps of establishing a communications protocol 
between die user terminal and a multiplex unit, said protocol being arranged such that 
messages sent therem may inchide data to be communicated and may spedty a 
drsrin a rion from amongst the plural remote devices and wherein said mateiplex passes 
die data to the specified destination remote device. 

20 ^ ^ 

In the above metiiod, Subsequent data sent by die user terminal to the multiplex unit 
may be co mm u ni cated to the previously specified remote unit witiiout the re- 
specification of said specified remote unit. The remote unit nday require re- 
specification after a pre-determined time limit. Hie protocol may be effective to 
25 establish aodientication details from the user terminal prior to passing data to and from 
tiie remote unit. 



In a further embodimrat of the present invention diere is provided a user uidt 
ooiTfyrising means for inputting and outputting information to and from a user; means 
for communicatmg widi a remote unit; means for receh^ing an identification conqionent 
of Che ^pe in which identification data is stored; and means for reading said 
identification data flx>m the identification component^ There may also be provided a 
remoter unit conqnrising: means for receiving and transipitting information to a user 
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umc; means for storing verification details inchidiDg data indicative of che identification 
data of pennitted users; and means for relaying information to networked devices upon 
the provision of positive verification details. There may also be provided a data 
communications system cooqirising the uso: unit and the remote unit as described 
5 above. 

The data communications system may also be embodied such that the storage means 
of the remote unit additionally relays stored account details to a networked device on 
be basis of ttie received identification data. The user unit may be a receiver/decoder. 
10 The conipoiient adapted to be received by the user unit may be a smartcard. 

The bivention also prSvidfes a method and apparatus substantially as described with 
reference to and as illustrated in the accompanying drawings. 

15 Features of one aspect may be applied to otti^ aspects; sunilarly , mediod features may 
be applied to apparatus aspects and vice versa. 

Preferred features of the present invention will now be described, purely by way of 
example* with reference.to.the accompanying drawings, in whidi:- 

20 

Ingure 1 shows the architecture of a typical digital television system; 

Figure 2 is a sclmnattc diagram of a receiver/decoder; 

Figure 3 shows an overview of an internet accSss ^tem; 

Figure 4 illustrates software layers in the user eq^pment of Figure 3; 

25 figure S shows Qie architecture of an mtemet access system; 

S ' 

Figure 6 shows the main components of an intern^ account manag^nent 
system; 

Figure 7 shows a part of the configuration of the internet access system in the 
case where the receiver/decoder- is not IP enabled; 
30 Figure 8 illustrates protocol layers of the system shown in figure 7; 

Hgure 9 diagrammatically illustrates the protocol adopted for communication 
between the user equipment and the gateway in the system of figure 7; and 

Figure 10 diagranunatically illustrates the protocol adopted for authentication 
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related communicatioii between the user equspment and tbe gateway in the system of 

An overview of a digital television system 1 is^ shown in Figure 1. The invention 
indudes amosdy amvendosal digital television system 2 that uses the loiown MFEG-2 
compression system to transmit compressed digital signals. In more detail, MPEGh-2 
Gompiessor 3 in a broadcast centre receives a digital signal stream (typ ically a stream 
of video signals). Tbe compressor 3 is connected to a multiplexer and scrambler 4 by 
linkages. 



The multiplexer 4 receives a plurality of fiuther input signals^ assembles the transport 
stream and transmits compressed digital signals to a transmitter 6 of the broadcast 
centre via linkage 7, which can of course take a wide variety of forms including 
telecommunications links. The transmitter 6 transmks electromagnetic signals via 
15 uplink 8^towards a satellite transponder 9. where they are electronically processed and 
biioad(^ via notional downlink 10 to earth receiver 12, conventionally in the form of 
a dish owned or rented^by ihe end user. Other transport channels for trazismission of 
the data are of course possible* such as terrestrial broadcast, cable transmission, 
combined sateUite/cable links, telephone networks etc. 

20 

The signals received by receiver 12 are transmitted to an integrated receiver/decoder 
13 owned or rented by the end user and connected to the end user's television set 14. 
The receiver/decoder 13 decodes the compressed MPEG-2 signal into a television 
signal for the television;.$et 14. Although a sq)arate receiver/decoder is shown in 
25 Hgure 1» die receive/decoder may ako be part of an integrated digital television. As 
used herein, tbe term "receiver/decoder" includes: a separate receiver/decoder, such as 
a set-top^box, and-a-televssion having a-receiver/decoder integrated therewith:: 

In a multichannel system, the multiplexer 4 handles a^dio and video informalion 
30 receiv^ from a number of parallel sources and interacts with the transmitter 6 to 
broadcast the information along a corresponding number of channels. In addition to 
audiovisual information, messages or z^plications or any other sort of digital data may 
be introduced in some or all of these channels interlaced with the transmitted digital 
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audio and video infbnnatioiL 

A conditional access system IS is connected to the multiplexer 4 and the 
receiver/decoder 13, and is located partly in the broadcast centre and partly in the 
5 receiver/decoder. It enables the end user to access digital tekvision broadcasts from 
one or more broadcast suppliers. A smartcard, c^aUe of deciphering messes 
lelatip^o oonmiexcial ofEos (tbat is, one or several television programmes sold by the 
broadcast supplier)^ Item 'be ins^led into the receiver/decoder 13. Using die 
receiver/decoder 13 and smartcard, the end user may purchase commercial offers in 
10 either a subscripdon mode or a pay-per-view mode. 

As mentioned above* programmes oransmitted by the system are soambled at die 
multiplex^ 4, the conditions and eociypdon keys sqfiplied to a ^ven transmission being 
determined by the access control system IS. Transmission of scrambled data in this 
IS way is well known in the field of pay TV systems. Typically, scrambled data is 
transniittBd togedier^^ a control word for desoaixriiling of d^ die control word 
itself being encrypted by a so^caUed exploitation key and transmitted in encrypted 
fbim. 

r 

20 The scrambled data and encrypted control word ^are then recdved by die 
receiv^deood^ 13 haying access to an equivalent to the e^loitation stored on a 
smart card inserted in ^ receiver/decoder to decrypt tbe encrypted control word and 
Uiereafter descramble the transmitted data. A paid-^up subscriber will receive, for 
example, in a broadcast monthly EMM (Entidement Management Message) the 

25 exploitation key necessary to decrypt the encrypted control word so as to permit 
viewing of die transmission. 

An intecacdve sys^ 16, also connected to the mult^lexer 4 and the receiver/decoder 
13 and again located pardy in die broadcast centre and pardy in the receiver/decode, 
30 enables die end user to interact widi various applications via a modemed back diannel 
17. The modemed bade channel may also be used for communications used in the 
conditional access ^stem IS. 
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Physical inieifaces of the receive/decoder 13 are used for downloading data. With 
lefoence V> Figure 2, the receiver/decoder 13 contains, for example, six downloading 
devices; serial interface 30, parallel interface 32, modem 34. two card readers 36, and 
MPEG flow tuner 38. 
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The broadcast and reception system is also used to provide internet services such as web 
browsing and e-mul. An iq)plication wUdi is nm by the recdver/decoder 13 enables the 
receiver/decoder to access intemet services and to displ^ web pages and e-mails either 
on television set 14 or via a cos^niter connected to the receiver/decoder 13. 



Refenin^ to Figure 3, an overview of the intemet access system will be described. User 
equ^m^t 20 (wh^ indudes^a receiver/decoder) communicates vnOi operator 22 via the 
public switched telq^h&ne networlc (PSTN) 24. The user equipment sends a request to 
the operator 22 to be seat ceitaindata^ for example, a particular we^ The 

15 operator recdves this request and outputs the request to intemet service provider (ISP) 
26: In response to this request, the ISP supplies a response to the opemtor^ which n^ght 
comprise a requested web page obtained from the intemet 27, or an e-mail wliidi was 
waituig for the subscriber at ^ ISP. The op^or delivers the response to the broadcast 
centre 28^ i^ere it is integrated into the MPEG bitstreami, for example as a private 

20 section, and transmitted by the transmitter 6 and received by receiver 12 as previously 
described. Where Ae receiver/deooder is IP-enabled, i.e. equipped with the protocols for 
receiving data from tiie intern^ ^e infomiation may be transmitted as an IP frame in the 
MPEG btt$tream» that is^ in the IP format. If the receiver/decoder is not IP-enabled then 
the data is sent in some other way, e.g. as a private MP&O section. The user equipment 

25 20 extracts the response from the MPEG bitstream and.displays it on a tdevision set or 
onac^pttterscreen. The response may alternatively be transmitted to user equipment 
20 via the PSTN 24. S ' 



The software levds employed in the user equipment 20 are shown in Figure 4. The 
30 application level comprises a web browser and e-mail application, which may be a 
commerdat ^iplicatson such as Netscape or Mcrosoft Internet Explorer and Outlook 
Express^ or an qiplication specifically designed to run on a receiver/decode:. Below the 
application levd are HTTP, socke^ TCP/IP, PPP/SUP and a driver level. The driver level 
is modified, as compared vn&i a browser application running traditionally on a PC, in that 
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His divided into amoden drive* fi>r conunumcatmg with the PSTN 24 via the modem of 
the user equipment and a tunor driver &r communicating via the MPEG flow tuner 4028 . 

Various configurations 6f the user equipment 20 are pos^le. In one configuration a PC 
S is not used and all of the user software runs on the recover/decoder 13. In this 
configuration the receiver/decoder 13 communicates with the PSTN 24 either via an 
intenial modem or via an extenial modem and the serial port. The receive/decoder 13 can 
receive Imemet responses in the bitstream from the earth receiver 12. The user interface 
is provided by a remote controller or keyboard and a television set connected to the 
10 receive/decoder 13. In this configuration, the TCP/IP (evd shown in Pigure 4 may be 
omhted, in which case a gateway located at the operator pro^des the necessary protocols^ 
as will be described later. 

In another configuration a personal computer ^C) is provided which is connected by its 
IS parallel port to the paralld port 3 2 of tlie recover/decoder 13 (or optionally by its serial 
port to the serial port 30 of ^ recdver/decoder 13). In this case» an upper portion of the 
softwa^levds Aawn m Figure 4 tun on the PC, and the roiling lower portion of the 
software levels run ojli receiver/decoder 13. The user interface is prodded by a 
keyboard and a monitor connected to the PC. 



20 



2S 



In a fiuthcr configuration a PC is connected to the PSTN 24 via an internal or external 
modem of the PC, In this configuration, the receiver/decoder 13 may be provided 
separatdy or m the form of an add-on or phig-in card of the PC, connected to the ISA or 
PCI bus tb&ttol 



The architecuire of the internet access system is shown in Figure S. Referriqg to Figure 
5, internet account management system (lAMS) SO is linked to internet service provider 
(ISP) 26 vifbkh provides s^ces such as web browsing and e-mail. The lAMS SO is also 
linked to subscribe' management system (SMS) 60 whiclw manages subscribers and sends 
30 requests^to the lAMS to grant or deny access to intemet.s^tces. Receive/decode 13 
is coni^ted to the lAMS via an internal modem, the public switched telephone nework 
(PSTN) 24. network a&ces^ sever (NAS) 36, and gateway 58. 



The SMS is also connected to Subscription Authorisation System (SAS) 61, which 
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manges authorisations and subscribers' orders for broadcast sendees, such as broadcast 
television services. The SMS runs the SAS and LAMS systmis in paraUd and ensures 
consistency between the two systems. Conunumcation between the SMS and the SAS 
and lAMS takes place usmg a real time TCP/DP Unk umig batch files. 

5 

Gateway S8 allows subscribers to access internet servic^ in real time. Such services 
include mail services for sending and receiving mail and other services which may be 
provid^ by ISP 26, and provisioning services and r^iinder services, which are 
provided by the lA^GS.S Fuscdonalty, the gateway 58 is a message router that enables 

10 coironuntcation with various different systems in a single modem connection. IMiere 
the receiver/decoder is not equipped with TCP/IP protocols for communicating with 
die ISP, the gateway also provides ^c necessaiy protocols for the receiver/decoder to 
cqmnumcaie widi die ISP, TTie receiver/decoder 13 dien ooimnunicates with tlie ISP 
via gateway 58, as indicated by line 59 in Figure 5. Where the receiver/decoder is 

15 equipped widi die necessary protocols, communication can take place with the ISP 
direcdy, as indica^ by dashed line 57 in Figure 5. The gateway comprises a 
communication server and an e-mail dispatcher. 



ISP tnter&ce 66 allows each modification related to a user*s account wluch takes place 
in the lAMS to be duplicated tq a user account in ISP 26 in chaise of hostiiig internet 
services^ such as mail services: Jt should be noted thM all information retatir^ to 
subset^ accounts is centralised in die lAMS, which ensures the manageme nt of TV and 
internet parameters. ne'IAN^ also matuiges die relationship between the internet 
parameters and TV paramews, through its mtofice widi Subscriber Management System 
(SMS) 60. SMS 60 manages subscribers and sends requests to the lAMS in order to 
grantor to deny access to internet sendees by subscribers. 

In order to set up an lAMS account, a subscriber first simds a request for a new account, 
together with infonnation such as requested e-mail address and sdected options, firom the 
30 receiver/decoder 13 to the lAMS 50. The lAMS checks the miartcard number of the 
subscriber against a fist of snuutcard numbers, obtamed firom subsoiber management 
system (SMS) 60, conespondo^g.to subscribers for which it may set up internet accounts. 
The lAMS then sends a, request to.the ISP to set 19 an internet account. Once the 
accoinithasbeensetup, iheISP rehmisanadmowledgeraent to the lAMS, together with 




f 



V 



A^/wr/V9 AW , m-m mmm 



0171 830 0001 P-^M^S^S 



f 



a password. The password is initiaUy deOned by the SMS, but may be modified later by 
the subscriber. The lAMS account information (password, e-mail address and internet 
parameters), is stored in the lAMS, along with Ae smartcard number of the subscriber. 
The lAMS informs the subscriber that his account has been set up. The subscriber can 
S then send aiid recdve mail to and from the mail server 28. 

The main components of the lAMS are shown in Figure 6. The main fimctions of the 

lAMS are as follows: 

o ma'tn ta mit ^ ft eentralified list of e->mail account parameters linked to subscriber 

10 parameters such as smartcard number 

o granting or denying access to internet services for a subscriber at the request 
of the SMS 

^ customising mtemet accounts at the request of subscribers (provisioning) 
o reminder sdrvice, which allows an e-mail user to register an event and to be 
IS warned by an e-mail at the time of the event 

o duplication service, which allows updates of the lAMS contents to be copied 
to a related server, such as an ISP 

Central to the lAMS is a rdational database management system (RDBMS) 70, which 
20 contains subscription information for internet services and e-mail accoimU, stored in 
storage means 72, SMS communication interface 74 allows the lAMS to commimicate 
witiithe SMS, so that the lAMS may be updated with the details of subscribers who have 
been granted or denied access to mail services. Proponing server 76 allows a subscriber 
to manage and customise his e-mail account. Reminder server 78 allows a subscriber to 
25 manage a fist of events. AnevCTtisrdatedtoasubSCTbet'se-xriailaccount Asubscriber 
may register an event and receive an automatic reminder a predetermined numb^ of days 
befor^e event via an automatically, generated e-mail« E-mail notification interface 84 
allows the EMNS 62 fo search for a subscriber's notification preferences in flie lAMS 
KDBMS 70 in order to send an over air notification message. Support server 80 allows 
30 an administrator to check the presence and the status of a subscriber or an e-mail user in 
tiie lAMS. Replication service 82 copies updates of the contents of the lAMS KDBMS 
70 to the ISP account management system. 



Requests which are sent to the lAMS fi-om recover/decoder 13 are directed to the 
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appropriate part of the lAMS, such as the provisioning server (for e-mail account 
management) and the reminder server (to manage renunder events), by the gateway SS. 

The intsiiet access system described above allows broadca^ service providers also to 
provide internet services. ' The operator of the system mamtains intmi^ accounts 
independently of interna sendee providers, so that the operator is not tied to a particular 
internet service provider. By linking togeth^ subscriptions to broadcast services and 
subscriptions to the internet, accounts for the two services may be managed together 
which may reduce the amount of processing involved, in comparison to the case where 
accounts are managed separately, and the subscriber may be billed together for the two 
services. 



Further details of die lAMS are described in co-pending patent application entided 
"Internet Subscrttier Management" in the name of the present applicant, the subject 
IS mattar of which is incorporated herein by referace. Fuidier details of the e-mail 
notification system aie described ULCo-penduig patent a^lication entitled "Metiiod and 
Appaiatfjsfijruse wiifa E-mail'' in die name of the present^plicant, die subject matter 
of whi^ Is incorporated herein by reference. 

20 Acoiifiguiationof die iiiternet access system m the case where die reoeiva 13 
is not internet enabled will now be described widi reference to Figures 7 to 10. 
Referring to Figure 7. which shows a portion of the system shown in its entirely hi 
Figuxe 5 but with ceitaha aspects delineated in greater detail* receiver / decoder 13 is 
of die type previously described in which the unit is not equipped with the tranqM)rt 

2S control protocol / intenet protocol (TCP/IP) nec^saiy for direct communication with 
die ISP 26. Communication, therefore, takes place via DSTB Gateway 58. The 
Provisioning server 76 and Reminding server 78 are shown in the figure as distina 
portions of the lAMS 50 and* in ^ embodimem» data is routed to eadi via sqiarate 
lines 76a and 78a as appropriate. 

30 

It will))4e qjpreciated, therefore, that diere are in effect four subsystems of mterest in 
any communication between the receiver / decoder 13 and any remote server desired 
to be accessed. These are die receiver / decoder 13 itself, the NAS 56, die Gateway 
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S8 and the remote s^er wliich in the embodimrat may be any one of provisioning 
server 76, reminding server 78. or mail server 64. The PSTN 24 is effectively data 
transparent In the fmhodrnient mail server 64 is accessed via interface 66 and the ISP 
26 but ttiis need ncft be die case and die mail server 64 could be direcdy accessed from 
the Gateway 58. Moreover, although shown as a siqgle unit in the figure, the mail 
server 64 may consist of two sqparate units, a first for sending emails (which may be 
for example a SMTP server) and a second for receiving emails (wliich may be for 
example/a IMAP served. In sudi an coafiguration. the Gateway 58 may communicate 
witti th^two units which conqirise die mail server via two sq)arate ports. 



The different protocol levels handled by each of the four above described sub-systems 
will now be described widi reference to figure 8« As will be seen from the figurct the 
receiver / decoder 13 has tow protocol levels as follows (highest level first): an 
iqn?llc^<^ l^el protocol i[wfaidi will be application dependent) and may, for exanq^le. 
IS be SMTP, IMAP or the like; a*Galeway protocol (this being the level used for the 
receiver / decoder - Gateway communication as will be more fully described below): 
a PP4 protocol and a modem layer such as v22 or v42 bis. The op^ation of these 
latter two layers will be well known to the skilled pmon. 

20 Tlie NAS S6 functk>ns at a single, protocol layer and is effective to convert the modem 
layer (used to communicate across die PSTN 24) to internet protocol TCP/IP. 

The Gatewi^ Si bas t}|ree,oparative protocol layers (again highest first), namely the 

Gateway protocol layer, the V?^ protocol l^er and TCP/IP. 
25 . ..• 

Fmally the remote server win gqaerally have two protocol layers an upper layer at die 
— application level protocol and a lower layer at TCP / IP protocol. 

The Gateway protocol therefwe allows die Gateway 58 to respond to messages and in 
30 appropriate cases identify the intended recipient of data and forward die data to that 
recipient The protocol also allows the receiver / decoder 13 to initiate various 
Gateway 38 / remote server operations. In die embodiment, the Gateway S8 is 
responsible for directing SMTP or IMAP data to the mail server 64; dbecting data to 



provisioning server 76 which may include requests to provide for the creation of new 
accounts; directing data to ttie reminder server 78 whidi inay include requests for event 
registration; constnictmg message to be sent to the receiver / decoder 13 on the basis 
of data received from any one of the mall seiver 64, the provisioning server 76 or the 
S reminder server 78 and handling the communication of such constmcted messages. In 
addition the Gateway has the ability to perform a receiver / decoder authentication 
function. 

The low level conmninication between the receiver / decoder 13 and the Gateway S8 
10 will now be described. As a first step, modem communication is established between 
die receiver / decoder 13 and the NAS 56 over PSTN 24. Any suitable modem format 
maybeused, fi)rexan9lev22orv42bi$. At this time a "chaf" sequence occurs at the 
modei^^level b^eea the receiver / decoder 13 axul the NAS^56 so as fully to establish 
the comnRnucations ch^me). Iliereafter die NAS 56 establishes a connection channel 
15 widi die Gateway 58 at Uie TCP protocol level. Following this event, a token is sent 
by the Gateway 58 to the receiver / decoder 13, diis toten being a pre-specified 
diaracter sequence. The receipt, of such a token by diie receiver /decoder 13 notifies 
it of the presmce of ttie Gateway 58 and a communications channel between the 
receiver / decoder 13 and the Gateway 58 at the gateway protocol levd is thereby 
20 established. v 

The established gateway protocol communications dhannel is» in effect, under the 
control of die recover / decode 13. It is die receiver / decoder whidi must request 
the channel before message exchas^e can occur. Additionally the disconnection 
25 procedure (described bdow) is msdgaled by the receiver / decoder 13 m order to dose 
the channel. 

■ : <. : - ■ V 

It should be noted ^iat,i in diis embodiment^ the gateway protocol allows the 
establisbment of a single TCP channel with a corresponding remote server* In oth^ 
30 words, in this embodiment, the receiver / decoder 13 cannot be connected to more than 
one remote server at any one time. However, die receiver / decoder 13 may establish 
and release connection to different remote servers widiout needing to eststbUsh a ftesh 
communications channel betweexi it and the Gateway 58. 
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It diould furtber be noted that, in the embodiment, the gateway protocol layer does not 
perform any error recoveiy innction since the lower level protocols (modem / TCP) 
ensure the transport of data and the upper level protocols (application protocols) 
perfonn.ertor handling. 

<^ 

The general message sbucture of communications in tiie (jateway protocol will now 
be described. Each message strucmre contains the following fields: 

{protocol version} {command identiiiar} {data length} [parameiers] 

where {*..} indicates mandatory fields and [...] optional fields. 



The message scroc^ure is the same r^ardless of whether the message emanates from 
the receiver / decoder 13 or the Gateway S8« The fields are binary encoded with the 
15 most significant bit first. 



The protocol version (PRT) field comprises a single byte identifying the protocol 
vttsionf V 

20 The command identifier (CI) field comprises two bytes aiKl identifies die type of 
message rq)resented. The various types of message will become apparent fiom the 
data exchange events descriptions outlined below. 

The data length (DL) field is two bytes in Iragth and identifies the overall length of fiie 
25 appended param^eis field (if aay). This permits die parameter field to be of variable 
length. If thm are no q^pended parameter fields, this field will contain a mo vahie. 



The parameters field is encoded m TLV form (Type Length Value) and contains any 
necessary parameters associated with the message. There are three categories of 
30 parameter which may be used either indivKiualfy or in combination dependent upon the 
type of message. In other words the type of message defines which of the parameter 
fieldS/Will be present. It will also be ^reciated that c^r|ain messages (fbr exana^Ie 
a message cotnmandi^g t|;iat die connection be reset (MG RCNX)) may not have an 
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associated parameter. 



The first type of paiameter (REMOTE SERVER) is used to identify the remote server 
and coDtaiDS an integer indicative of whetiier the server identified is the STMP portion 
5 of the mail server 64, tlie IMAP portion of the mail server 64, the provisioning server 
76 or the Reminder server 78. In the embodiment, this parameter is two bytes long. 
In a modification tfie paramfiCT could be used to identify other or additional $^vm. 

The second (ype of parameter (BODY) is used to contain data received from or to be 
sent to^iemote server of interest. This parameter is of variable lengdi as defined by 
die data length field %ence meaning Aat the data packages need not be of pie- 
d^ermined length, A maximum length of this parameter is predefined. 

The third type of param^ (ERROR^COD^) is used to identify an error condition. 
15 This may be used to indicate, for exan^Ie, when the Gateway is unable to open a 
connection wiOi the specified remote s^er, when connection has been lost with the 
remote server^ when a error is* detected in a message received ftom die receiver / 
decoder 13, when no data has been received from a remote server following a 
command from the receiver / decoder 13 or when audientication has faUed. In the 
20 embodiment, this parameter is two bytes in lengdi. 




30 



In a modificadon, diere may be a fourth type of parameter used to contain 
audient|cation d^ails. ^ 



25 A typical data exAang^ sequence representative of nomial dialogue over die Gateway 
protocol levd communicaiions cbannel will now be desoibed wiA reference to Figure 
9: This shows diagrammatically (he messages between the receiver / decoder 13 and 
the Gateway 58 togeOer with the ccuiespond^ ev»ts occurring between the Gateway 
58 and a selected remote server over a time period (time increasing down the pa^). 



The first event series (el) shown is the gateway protocol level connection procedure 
between the receiver / decoder and the ^^ecified remote server. The receiver / decoder 
13 sends a message 1000 requesting connection (MG_CN30 containing two 
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paiam^^, a R^OTE_SERVER parameter specifying the server to which it desires 
to coiuluct a dialogue ^ z^BGDY parameto' which encapsulates data addressed to the 
remote server (if any). This causes the Gateway to perform two tasks collectively 
designated connection 1001 on.the Figure, namely to establish coimection with the 
5 specified server via the appropriate link ai^ send via that link to die q>ecified server 
the data (if any) contained in the message BODY parameter. 

Following the above sequence, the remote server sends data 1(X>2 to the Gateway 58 
for onward transmission to the receiver / decoder 13 . The Gateway encodes this in a 
10 "data exchange with remote server (MG REMOTE) message 1003, having a single 
parameter field, namely BODY which contains this data and sends ttie message to the 
receiver / decoder 13. A connection is thereby established. 

The second event series (e2) shown is a typical data exchange sequence. The sequence 

19 comm^ces with tiiie sending by the receiver / decoder 13 of a "data exchange with 
remote server" (MG message which contains data destined for the server in 
the field parameter BODY, As will be appreciated, the receiver / decoder 13 only 
communicates widi one remote server at aiQf one time and hence as 0ie server will have 
been already specified by the connection message (e2), it does not require to be 

20 specified during ordinary data exchange. The receipt of this data exchange message 
1004 by die Gateway 58 caus^ it to pass the data therein to tiie remote server in the 
communication designated 1(X)S. 

-. , * 

The remote server may, thereafter, send data to the receiver / decoder (desi^iated 
23 1006, 1007) as previously described. 

^ A further feature of the embodiment will now be described with reference to the 
commuiiications designated 1008a« 1008b and 1009. ThCk^'data exchange widi remote 
servcr^(MG_REMOT^ message Of die type sent from the Gateway 58 to Uie receiver 
30 / decoder 13 includes a minimum data paclcet size. The Gateway 58 wiU not, 
therefore, send a message to die receiver / decoder 13 until a pre-determined m^ni^!^*^ 
amount of data has been received from the remote server (in effect a minimum data 
amount direshold) or until a pred^eimined tin^ has elapsed from the receipt of the last 
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data from the remote server (in effect a time out). Thus althou^ communication 
1008a reptesents data transfer from tiie lemote server to the gateway 58. the quantity 
of this data is lower than the predetermined threshold and hence no message is sent to 
tlie receiver / decoder 13 at this time. Next a further data transfer 1008b between the 
5 occurs from fhe remote server to the Gateway 58. Thi\transfer results in sufficient 
data b^g communicated to &e Gateway and hence it sends a data exdiange message 
1009 whidi hidudes bmh data sequences 1008a, 1008b. In a similar manner, race the 
quantity of data recdved t>y the Gateway 58 ftom ttie remote server exceeds a 
maxinmim amount, a data exchange message is sent to the receiver / decoder 13. In 
10 such an event, a single data exchange sequence between the remote server and the 
Gateway 58 may result in plural messages between the Gateway 58 and the receiver / 
decoder 13. 

In the embodhnent the tuneout period is 200 milliseconds (ms), the m^nhTwim data 
IS received threshold is 128 bytes and ttie maximum data teceived due^old is 512 bytes. 

Although not shown in tbe figure, it may arise that the Gateway 58 receives no data 
from the remote server within a pre-determined timeout period which, in the 
embodiment is 5 seconds. In such an evem, the Gateway^^nds an "error detected by 

20 Oatew^" (MG^ERR^R)^ roe$s.age to the receiver / decoder 13 which includes a 
parameter field of tiie ERRORi.CX)DE type, the contents of this field specifying the 
occurrence of such an evem« The receiver / decoder 13 is r^ponsible for whatever 
further action it would like to take whic^ may include the sending of a "reset 
communication" (MGJRCNX) message whidi causes die Gateway 58 to close the TCP 

25 coxmection with the remote server. 

As foreshadowed above, similar error messages may follow otiher events sudi as an 
inability to open a connection with the remote server, a loss of connection with the 
remote server or an erroneous message ftom the remote server. En the latter case this 
30 may include the receipt of data from the remote server by dtie Gateway 58 of an 
unknown type, of incorrect length, of an inapplicable value or having an unknown 
protocol version. 
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Returning to Figure 9, tiie event of disconneGiion from die remote server (e3) will now 
be described. This event is initiated by the receiver / decoder 13 sending a 
''disconnect" (MG_DCNX) message 1020. This message may include data to be 
passed to the remote server in a BODY parameter. This command and data 1021 is 
S passed to the remote server and the Gateway 58 then waits for an acknowledgemCTt 
and reply dam 1022 if any. Subseqitendy, the Gatewsy 58 disconnects from the remote 
server (1023) and sends a message 1024 lo the leodver / decoder 13 whidi indudes 
the received data if any. Alfhoagh not shown hi the figure at the low protocol leveU 
die zeodver/de<XKla- 13 may dien close die CQoneaion at modem leveL TheOateway 
10 58 will thereafter be notified by the NAS 56 diat die TCP connection is closed. 

The aulbCTiication process proviifed for tiy die Gateway protocol will now be described 
with reference to Flgm:e 10. This may be required for various services, for exanq)le 
provisioning services* before estabUshmeot of a conmmnications channel. Tbe 

IS Gateway 58 contains information npon which servers require autbenticatioa jMrior to 
access and when it receives a "connecdon request" (MG_CNX) message 1100 for such 
a server it responds widi an "authentication request" (MG^AXJTMiiBJMaj) message 
1101. Such an audientication request message has no accompanying patame The 
receiver / decoder 13 must thereafiter respond with an appropriate "authentication* 

20 message 1102. This m^ss^e lu&an associated parameter wMch indudes audi^^ 

data wlddi may, for example, be the smartcard number, as more fiiUy set out below. 
Theaudienticationdatamay be passed ma BODY Qpe parameter or, in a modification 
may have its own parameter type. 

25 If the Gateway 58 ^ji^es ;die authentication details to be cwrect then the 
audientication is successfol (indicated graphically be event 1103) and the Gateway 58 
establishes a connection 1104 with the q^ecified remote server. The Gateway 58 
rqxms that the authentication-is successful by sendii^ a data exchaiige message 1 106, 
wludi will include any data 1105 received from the remote server in response to the 

30 opening of tiie connection. In die case where authentication fails, an err<»r message 
(MG^ERROR) is sent which* indudes a parameter indicating such a faihire as 
previously outlined. 
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Rebiming to the system sliown in Figure 5, it is possible to identify two distinct types 
of *'aoQ@int" for die aocessiag of iotemet services and the like from receiver / decoder 
13, namely a so-call&l "tonnection account" and a so-called "directory account". 
Within every connection account there may exist plural directory accounts. 

S 

A connection account provides the basis upon which a subscriber may access flie 
operator netwodc A subscriber will be allocated a sii^le connection account per 
operator although this may be associated widi several connection protocols as more 
flilly desojbed below. The method by which authentication of such an account occurs 
10 is at the network level and will also be described in greater detail below* 

The procedure upon usct login by means of his connection account will now be 
described. As will be appreciated, the idemification data supplied upon log-in must be 
unique ui Older to pemiit the user to be identified by diel^ In the embodiment^ 

15 this is^ achieved by die use of a so-called MSD numbe((, which is at least partially 
derive^HOrom die smartcaid number of die user's cqiiq)ment. In addition* upon log-uu 
the user must specify the communications protocol which may vary in dependence 
iq)on, fbr exan^le, whether the user is attonpdng access via a dial-up modem 
associated with a computer (which may use, for exalI^)le, MediaWebPC a product of 

20 Canel+) or via the type of receiver / decoder unit such as that commonly referred to 
as a ''set-top box". The protocols used may, for example^ be PAP, CHAP or PPP for 
dial-up modem. 

The login information includes, therefore, of the MSD number of die user, a field 
25 identifying the type of user terminal, a field specifying the type of data return to be 
utilised, a field indicaiiog the cliem version nund^er and, if applicable, die so-called 
RADIUS domain name of the client.' The logm wiU also bclude a password. In the 
embodiment, Oiis information is formatted as follows: 

30 login = ^ , i 

{maijnmiber} {tenxdaal type} {returnj^pe} {version} [@RADIUS_doinaui_name] 

Eadi of tiie above fields will now be explained in ftiller detail. 
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Tho man^number field itself consists of &e following string of fields: 

{msn.number} » {RSMC} {RSMN} {chck} 

S Tlie first of tbe MSN data fields contains tlie reniovabl& security module product code 
(RSMQ^cliidtttiflesilie^peofsaiaricafd. This idot^fication of type inayiii^ 
data in^cative of the one or mote aspects of the technical make-up of the card, the 
manufacturer and the ^^mimercial operator who has provided die card to flie user. In 
the embodiment, this field is of two bytes in length and may contain four digits. 

10 

The second of the MSN data fields contains the removable security module number 
(RSMN)* This field Includes a code whidi identifies a smancaid in use. Such code 
is prefoably pie-programmed by the smartcard supplier and is unique to die smancacd 
and hence die user, dierdtqr allowing idendficadon of die user. In the embodiment this 
IS field is four bytes in length and may contain fifteen digits. 

The final field comains check data (dick) which may be calculated by any known 
method, fbr example, it may be a checksum, 

20 Ihe teiminal^Q^ field will now be explained. As explained above* die terminal may 
be of Me so«called "^-top'' box variety or may be a con^uter havtaig a modem 
faciliQr, The field will take die value*?'' fbr a PC ^terminal 
a s^-top box teminal type. U win be ^predated diat the field could, more precisely 
specify die terminal type and that the provision of such a fieLd also permits future 

25 expansion by the definition of further and alternative terminal types. 

^^The renmijirpe field, perauts the spedfication of die mediod by whidi return data is 
sent to die user. Inihe onbodiment, the fidd takes the value "M*' when all return data 
is to be miied via the modem and the value "S" when data return is to take place over 
30 both satellite and modem channels. Again die possibility of future expansion in the 
methods of providing return data is provided for. 

Ihe version data field allows version data to be passed from die receiver / decoder 13 

^— ' 
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to the network. In the embodim^ this is sei ai 01 as a default. 

Hie optional field RADIUS_domainjiame pranxts a client's authendcation request 10 
be routed to a Ihtid part auflientication server which may permit the provision by such 
a third party of gateways ta» for example, different service provider. 

The conne^on profile will also comain a password field which, in die embodiment, 
has a maximum lei^gth of 14 alphanumeric characters. 

Return now to describe the directory account dus provides die basis for the accessing 
of uidiyidual internet services, for exanqde proxy widi Identification, tnall, news et 
cetera.^ A subscriber's directory accounts are linked to his connection account. In 
distinction, however, to a connection account^ authentication of a directory account 
occurs at plication level. 

As previously stated, die directory account allows the access to divers internet services 
from the receiver / decoder 13. A directory account will generally consist of: 

- an identifier and password; 

- one or more so-called "e-mail aliases"; 

- in q^ropriate cases, other data relating to the services offered to the 
subscriber. 

The idoiifer (in s^iprcpriate cases in cnmhination with the password) is used to control 
the access by the subscriber of various ISP servioes,'*^(or example access to the 
subscriber's mailbox. ^>thfr examples include access to private websites, directories, 
coxitrol of access to services, certificates, "mailgroi^)** registration and the like. 



The identifier may also be used to receive e-mails address in the format 
"identifien^omatn% in i^iich event the subscriber may need to use his password 
when accessing the mailbox identified by the identifier. 

The e-mail aliases provide for the facility of e-mail receipt by the e-mafl server of 
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messages address to "alias@doiiiaiii". 

In an ^bodixnent, several directory accounts may be associated with a single 
connection account (s^-cailed "fiamily subscrqition''). &i sucb an event, it may be 
S possible for a user initially to specify tlie number of directory accounts wbich are 
permissible for each connection account, although it should be noted that each identifier 
and alias must be imiqiie. 



10 Terms 



The following terms are used herein: 



I^Agcoi 



E-mail 



&mail Id 



lunt 



B-mail Address An E-mail address is composed of two fields: the E-mail ID and 
15 the domain name. The form* of an e-mail Address is e- 

mail_Id®Domain_Name. 

^n ^-mail Account provides information about the user that a 
Mail Server needs to process that user's messages. 
The prefix of an e-mail address. An e-mail Id is unique in a 
20 domain name. 

E-mail Notificr The e-mail Notifier System allows subscribers (EMN) to be 
notified as soon as ih^r receive a new e-mail in dieir mailboxes^ 
A short message is sent to thek STB over-air. 

Internet Account 

25 Management System A syst^ managing subscriber TV account Management 

parameters and related E-mafl Accounts System (lAMS) 
parameters 

Mailbox Messages stored for IMAP delivery are held in a mailbox. A 

mailbox, on a mail server must be uniquely identified by a 
30 ^ mailbox Id. A mail server hosting different domain name can 

i|iot 6onsi4er diat the e-mail Id is unique on ttie Mail server, so 
the mailbox Id must be the Email address* 

Mail Server Program that exchanges e-mail with odier Mail Servers and 
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10 



20 



Message Queue 
Server (MQS) 
Provisiomiig 
Server 



accepts and delivers messages to mail clieats. 
A message management system. 



Reminder Server 
Set Top Box 



Allows subscribers to create and customise e-mail accounts 
themselves. 

Allows a user to register an event and receive an automatic 
rj^ninder via an automatic mail. 

The compldteiy assembled, ready to use (SIB) digital decoding 
hardware* manufactured in accordance with Digital Video 
Broadcasting standards, CANAL + TECHNOLOGIES 
specifications. It is used as a digital decoder for transmitted 
video, audio, application and data streams so that ttie end user 
can access television programs and services. 
Cards that electronically store the secret keys of one or more 
conmierciai operators and otfa^ access mformation. 
A subscriber is related to a TV account (l.e. a SmartCaid 
number). 
SubSCTiber Managmient 

System (SMS) A system managhig data relatuog to subscribers. 



IS SmartCard 



Subscriber 



User 



A user is related to an e-mail aocohni. There may be multiple 
^^et^ for a shigle subscribe. 



It will be understood Aat the present hivention has been described above purely by way 
25 of example, and modificadons ot detail can he made within the scope of the invention. 



Eadi feanire disclosed in die description/ and (where appropriate) the claims and 
drawings may be provided independently or in any appropriate combination. 

30 Reference numerals appearing m the claims are by way of illustration only and shall 
have no limiting effect on die scope of die claims. 
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CLAIMS 



1. A method of authenticating communication between a receiver/decoder and a 
remote server, comprising using an identifier of the receiver/decoder to authendcaie the 
S GommunicabOA. 

2r A method accordmg to claim 1 wherein the identifier is based on an identifier for 
access to broadcast services. 

10 3 . A method according to claim 1 wherein the identifier is stored together with an 
identifier for access to broadcast services. 

4 . ^ method according to ai^ of the preoeding claims wherein the identifier is stored 
on a removable componrat. 

15 

5. A method according to any of the preceding claims wherein the identifier is 
independent of a network logui identifier. 

6. A method according to airy of the preceding claims wherein the identifier is based 
20 onanumberuniquetoasmartcard. 

7. A method according to any of the preceding claims wherein the remote server is 
for acces^ng the internet. 

25 8. A method according to any of daims 1 to 6 herein the remote server is an 
intemqt^account management system. v 

9. A method according to any of the preceding claims where'm the remote server is 
for accessing a noetic having network protocols, and data from the recdver/decoder is 
30 converted into data compliant with the networic protocols at a remote tocation firom the 
receiver/decoder. 



1 0, A method of communicating between a receiver/decoder and a remote network 
wherein the protocols necessary for communicating with the remote network are 
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implemented at a remcfte location fiom the receiver/decoder. 

11. A method according to any of the preceding claia\$ wherein the remote server 

incbid^n identification database and the identifier of the recdver/decoder is used for 
S > 

S the retrieval of account details from said database. 

12. A meOod aooonfing to any of the preceding claims wherein said remote server 
comprises a datapath to an internet service provider and wherein said method further 
comprises the steps of providmg retrieved account details to the internet service 

10 provider and establishing a bi-directional data pathway between the receiver/decoder 
and the internet service providCT« 

13. A method according to any of Ae preceding claims wherein said identifier is 
acconqiaxued by data indicating the data pathway to be used for communication 

15 between the receiver/decoder and die remote server, 

14. ^A mediod of communicating data from a non-ime^net protocol enabled user 
termini to one of plural internet protocol enabled remote devices, the method 
comprising the 8tq>s of establishkig a communications protocol between the user 

20 terminal and a multq>lex unit, said protocol being arranged such that messages sent 
dierein may include data to be. connnunicated and may specify a destination from 
amongst the plural remote devices and iTidierein said multiplex passes the data to the 
specified destination remote device. 

2S IS. A reoeiver/deooder for recetvtng broadcast signals^ wherein the receiver/decoder 
is adapted to communicate with a remote server using an identifier of the receiver/decoder 
to uhhehticate the ckiniinimicauoh^ 

16. A receiver/decoder according to claim IS wherein the identifier is based on an 
30 identifier for access to broadcast services, 

17. A gatew^ whic^h is adapted to receive data fi-om a receiver/decxMier, wUch data 
are not in internet protocol, ^and to convert said data into internet protocol for 
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tFansmission to an internet service provider. 

18. A gateway for use in a data communicaiions system of the type which includes 
a user unit and plural remote devices the gateway unit comprising: 

5 means for sending and receiving messages to and from the user unit; 

phiral ixqmt / output ports each suitable for connection to an individual one of 
said plural remote devices; 

means for processing a received message so as to identify the remote device 
with tn^user unit wishes to establish a communications chiannel; 
10 means for passing' data forming part of received message and subsequently 

received me^ag^ to the identified ronoie device via the ^propriate input / ou^ut port 
and for converting data subsequently received from the remote device via the 
appropriate input / output port into messages for communication to the user umt 
thereby establishing a communications channel between the user unit and the remote 
IS device. 

19. A gateway according to cdaim 18 further comprising: 
means for identifying a message from the user unit commanding termination of 

the communications channel; and 
20 means for passing a temiination command to the previously identified remote 

device, 

20* A gateway according to. claim 18 or 19 further comprising: 

means for detemiming whdher audientkration of the user unit is required before 
25 the communications diannel is established; 

means for sending a message to the user unit requiring authentication hi sudi 
a case; ~ — 

means for analysing a n^umed anthcnticatiftn mfeyagfe mHndiy ig fl^thgnricfltinn 
data received from ttie user unit and establishii^ said communications channel when 
30 said authentication data is deemed valid. 

21. A gateway accorduig to aisy one of claims 18 to 20 wherein the gateway is 
adapted such that oomnumications between the gateway and the user unit take place m 
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a first format and coimnunications between the gateway and the iraiote device take 
place in a second fonnat. 
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ABSTRACT 

COMMUNICATION METHODS AND APPARATUS 

S A ]net%d of authenticating oommuiiicatioa between a receiver/decoder and a remote 
server is disclosed. Tb^method comprises using an idratifier of the receiver/decoder to 
authenticate the conununicatioa The identifier may be based on a smartcard number. 
Also disclosed is a gateway which is adapted to receive dau from a receiver/decoder, 
which data are not in internet protocol, and to convert said data into intmiet protocol for 
10 transmis^on to an internet sovice provider. 

(Fig. 7) 
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